Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add script to build migrations with datastore plugin #126

Merged
merged 9 commits into from
Jun 17, 2021

Conversation

gammazero
Copy link
Contributor

  • Update documentation

Base automatically changed from feat/issue-98 to master April 5, 2021 20:12
@Stebalien
Copy link
Member

@aschmahmann status?

@aschmahmann
Copy link
Contributor

@gammazero do you mind rebasing this on master and then we can do a walkthrough on how this works and make sure the script is mergeable?

@gammazero
Copy link
Contributor Author

I needed to update the go-ipfs dependency for fs-repo-10-to-11 because the plugin build script gets the go-ipfs dependency from the migration's go.mod file and the version that fs-repo-10-to-11 previously had was not found in github.

@aschmahmann
Copy link
Contributor

@gammazero hmmm... I see we accidentally did a force push ipfs/kubo#7857 (comment). I restored the branch but we should probably update anyway.

If the script works now that I've restored the old branch then let's drop the update from this PR and just do it in another one ideally once the next go-ipfs release is out. Otherwise, we can make a PR that just updates the deps now and have this PR build off of that one.

I want this PR to be two files instead of 700 😄

@gammazero
Copy link
Contributor Author

@aschmahmann After restoring the old branch, the script works. Now the PR has only one change.

The distribution at /ipfs/QmaaN2kipZfUpRSzwvUeG4Xi3yp1JJB294Vj8pnZ24hesF is no longer available and this is causing a sharness test to fail.  Updated the test to use the current distribution.
build-plugin.sh Outdated
@@ -0,0 +1,118 @@
#!/bin/bash
#
# Building migrations with datastore plugin
Copy link
Contributor

@aschmahmann aschmahmann Apr 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How much of this is datastore specific, or just arbitrary Go plugins (e.g. could IPLD plugins work too)?

I see there are some implied datastore plugin names, but the plugin names could be separately specified. Is there anything else?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assumed this was only for datastore plugins, but I guess it could be built with any. This is just for building a filestore repo migration, so does it even make sense to support any plugin? I do not know.

Do I need to add another argument, or prompt, for the name of the plugin?

build-plugin.sh Outdated

function usage() {
echo "usage: $0 plugin_repo x-to-y ...">&2
echo "example: $0 github.com/ipfs/go-ds-s3 10-to-11" >&2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two feature requests I'd add here, that can happen after we merge this initial one but would be nice to have are:

  • Being able to choose the version of the repo not just the repo itself (e.g. I might need to build an old migration against an old version)
  • Being able to add multiple plugins to a given binary

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • A user can now specify the version of the migration by following it with @<version_or_hash>
  • The script builds a single migration, with one or more plugins.

Example:

./build-plugin.sh 10-to-11 github.com/ipfs/go-ds-s3 github.com/ipfs/go-ds-swift@v0.1.0

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, looking forward to giving this a spin.

Script now builds one migration, but with any number of specified plugins.  Example
`./build-plugin.sh 10-to-11 github.com/ipfs/go-ds-s3 github.com/ipfs/go-ds-swift@v0.1.0`
Copy link
Contributor

@aschmahmann aschmahmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the job for the repos tested, but makes some assumptions about the plugins system we should spell out.

Also, let's add a note in the README that this script exists and might be very useful to people who are running into problems migrating their go-ipfs nodes that use plugins.

build-plugin.sh Outdated
Comment on lines 81 to 82
local plugin_name="$(echo $plugin_repo | rev | cut -d '-' -f 1 | rev)"
local ds_name="${plugin_name}ds"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure that the name of the plugin as added to the preload_list is only used for populating the import directives in the code generation script https://github.com/ipfs/go-ipfs/blob/master/plugin/loader/preload.sh.

It'd be nice if the user could set this in case they somehow end up with a conflict, but I don't think it should matter/come up for almost anyone.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

When a plugin name conflict is detected, suggest a new name by appending a "1" to the current name. If running interactive, then ask the user to use the new name or provide one. If running non-interactive, then keep appending "1" until no conflict.

build-plugin.sh Outdated
pushd "$BUILD_GOIPFS"
go get "${plugin_repo}@${plugin_version}"
popd
echo "$ds_name ${plugin_repo}/plugin 0" >> "${BUILD_GOIPFS}/plugin/loader/preload_list"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

${plugin_repo}/plugin 0

This part is incorrect/needs to be configured by the user. The actual subpackage that the plugin is in is totally configurable by the user and so should be something passed in by the user. This doesn't seem like it's too bad since we can just rip it off of the URL that's passed in.

The 0 part is hopefully fine for almost everyone, but technically this can either be any number or '*' and the user should be able to configure it. This is maybe more annoying to pass in, if we needed to default to something maybe choose * since it's what we use in our preload examples https://github.com/ipfs/go-ipfs/blob/0ae9b2b9034a57e02df419fe72f705f5a5b3b9c7/plugin/loader/preload_list.

Copy link
Contributor Author

@gammazero gammazero Apr 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this needs to be specified for each plugin that is build, I think it makes for a much less messy command line if the user is asked interactively about which plugin to load. Now, for each plugin repo build, the user gets a prompt that looks like:

For github.com/ipfs/go-ds-s3, load 'plugin *' [y/n]?

If they answer n, then they are asked to for a different value.

The prompting can be avoided by using the -y flag as the first argument to the scipt.

When a plugin name conflict is detected, suggest a new name by appending a "1" to the current name.  If running interactive, then ask the user to use the new name or provide one.  If running non-interactive, then keep appending "1" until no conflict.
- README describes how to use the build-plugin.sh script to build a migration with plugins.
- Display help with `build-plugin.sh -h`
@gammazero
Copy link
Contributor Author

@aschmahmann Added section to README to describe build-plugin.sh script and how to use it. Script also displays help when given -h flag.

@aschmahmann aschmahmann merged commit ea2bc1a into master Jun 17, 2021
@gammazero gammazero deleted the feat/build-with-plugin branch July 3, 2021 06:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants